Site Reliability Engineering: How Google Runs Production Systems
システムは自律的に動くわけではない → どう動かす……？
SRE チームの担当 : サービスの可用性、遅延、パフォーマンス、効率、変更管理、監視、緊急対応、およびキャパシティ計画
SRE チームが環境 (本番環境だけでなく、製品開発チーム、テストチーム、ユーザーなど) とどのように相互作用するかについての関与のルールと原則を体系化
100 % の信頼性を達成しようとするのは、コストが高くつくだけでなく、サービスやユーザーにとっても悪くなる
提供できる機能が減ってしまうなど
SRE は、単に稼働時間を最大化するのではなく、リスクやイノベーションとサービス運用のバランスをとり、総合的な満足度を最適化する 信頼性を向上させる際のコスト性の 2 側面
冗長化された計算資源
機会費用 : エンジニアリングのリソースを信頼性向上に充てることによるその他の機会損失
サービスが負うリスクと、ビジネスとして許容できるリスクを明確に一致させる
十分に信頼性を向上させるが、必要以上には向上させない
サービスリスクの特定
客観的な指標を特定し、目標を持つ
リスクとして単一の指標に還元することが難しい部分もある
Google では主に 「予定外のダウンタイム」 に焦点を当てる
時間ベースの可用性は使わず、リクエストの成功数による可用性を用いる
グローバルに広がるサービスを見るため、時間ベースの可用性は通常意味を持たないらしい
nobuoka.icon ある地域ではダウンしていても、別の地域では利用可能、とかもあるから、ってことなのかな
バッチなどの非サーバーシステムでも使いやすい
サービスのリスク許容度
SRE はプロダクトオーナーと協力し、ビジネス目標をエンジニアリング可能な明確な目標に変換する
消費者向けサービス (consumer services) と基盤サービス (infrastructure services) ではリスク許容度の考え方が異なる
基盤サービスには様々なクライアントがあり、要件が多岐に渡る
基盤サービスへの種々の要求を満たすために信頼性をめっちゃ高くするのはコストが高すぎる
インフラを分けて、異なるサービスレベルで提供する方法がある
特定した許容範囲を用いて、エラーバジェットにより信頼性の低さを管理する
製品開発チームと SRE チームの間の緊張関係 → エンジニアリングにかける労力についての意見の違いが発生
Google における実践
実際の稼働時間は監視システムによって測定
上記の 2 つの数値の差が、信頼性の欠如の 「予算」
エラーバジェットが残っている限り、新しいリリースを行うことができる
メリット
製品開発と SRE の双方がイノベーションと信頼性のバランスを見つけられるように共通のインセンティブを提供 Google では、運用作業 (= toil) を SRE の業務のうち 50 % 以下に抑えるという明確な目標 用語
モニタリング : システムに関する定量データの収集、処理、集約、表示 アラート : 人に読んでもらうためにシステムに送信される通知 モニタリングの目的 : システムがいつ壊れたかや、何が壊れようとしているのかを知れる
システム自身で修復できない場合は、アラートで人に知らせて人が判断
人への通知は高くつく (従業員の作業やプライベートを邪魔することになる) ので、アラートにノイズをのせないように
10 〜 12 人の Google の SRE チームだと、典型的には 1 人 (あるいはそれ以上) が専任で監視システムの構築と維持を担当
監視システムは、より速く、よりシンプルなものにしていく
監視システムは、 「何が壊れているのか」 (症状) と 「なぜか」 (原因) に答えられる必要がある
Google SRE では、ホワイトボックス監視メインでブラックボックス監視を少量使っている
ブラックボックス監視は、現在発生している症状を示す
4 つの重要な信号
トラフィック : システムにどれだけの需要が発生しているか？ (HTTP リクエストの量など) エラー : 明示的 (HTTP 500 系)、暗黙的 (HTTP 200 系でも正しくない、とか) なエラーとポリシーに反するエラー (例えばレスポンスに 1 秒以上かかったらエラー、とか) の割合 サチュレーション : 最も制約されているリソースの使用率 (メモリが最も制約されるシステムであればその使用率) 指標の裾 (tail) が長い場合もあるので、平均値などではなく値の分散を取ると良い
解像度を適切に選ぶ (1 分ごとの CPU 使用率は間隔が長すぎて見逃すし、年間ダウンタイムの測定に 1 分ごとのリクエスト集計は頻繁すぎる)
頻繁な計測のコストを下げるために、毎秒計測した上で 1 分ごとの分散を集計する、というような手を使える
監視システムは複雑になり得る → シンプルさを意識して監視システムを設計すること
監視に関する決定は、長期的な目標を念頭において実施すること
短期的な可用性やパフォーマンスへの打撃と、長期的なシステム改善はトレードオフの関係になりうる
呼び出しへの対応は、人を長期的な改善から気を逸らすため
Bigtable でアラート数が多くて長期的な改善ができなかったので、SLO を緩めたりメールアラートを切ったりした Gmail における、人が予測してスクリプト的に応答できる呼び出しへの対応 自動化は、メタソフトウェアとみなせる : すなわち、ソフトウェアに作用するソフトウェア
システムが一貫性のない状態になったりする
Google では外部化された自動化は必要ない
内部化した方が効率的だし、つなぎこみのロジックがない方が良い
フェイルオーバーする頻度が増えたが、それを自動化
セキュリティ観点で、自動化が推進された
sshd の利用から、ACL 駆動の RPC ベースのローカル管理デーモンに 安定性 (stability) と機敏さ (agility) の間のバランスをどうとるか？
単純さは信頼性の前提条件
退屈であることは美徳
エンターテイメントとは違って、ソースコードには驚きは不要
本質的な複雑さ (対象とする問題領域の複雑さ) はしょうがないが、事故的な複雑さは減らすべき
SRE としては、自分たちに責任を持つシステムが複雑になるときにはそれを押し戻し、複雑さを減らすように努力する
SRE は、すべてのコードが本質的な目的を持っているようにするためのプラクティスを推進する
コードが実際にビジネス目標を推進していることを確認するコード精査
デッドコードの定期的な削除、などなど
SRE 的にはコード追加は新たなバグの追加の原因になりえる
追加するものがなくなったときではなく、削除するものがなくなったときが完成
最小限の API を構成する
モジュール性は重要
チームとビジネス所有者が合意した呼び出し応答時間で対応する (ユーザー向けやタイムクリティカルなものだと通常 5 分、それ以外は通常 30 分)
主と副のオンコールローテーションがある場合が多い
それぞれの役割はチームによって違う
課題に対して論理的に、適切な認知で対処するために、ストレスがかからないことが大事
重要なオンコールリソース
明確なエスカレーションパス
明確に定義されたインシデント管理手順
過負荷になるようであれば、四半期ごとの計画で過負荷解消の目標を立てる
一般的な問題解決手法
具体的なシステムの知識
理論
システムに問題があることを示す情報が出発点
システムの状態を調べ、システムの構成などから可能性のある原因を特定する (仮説)
2 とおりの方法で仮説を検証
仮説を確かめられるシステムの状態を確認する
制御された方法でシステムを変更し、結果を確認する
根本原因を特定できるまで繰り返す
実践
問題の報告があったら、次は、それに対して何をすべきか判断
問題の重要度によって適切な対応は異なる
大規模障害の場合、根本原因の特定よりも、動く状態に戻すことが大事
システムの状況を把握するために、各コンポーネントの状態を調べる : 監視システムやログ
Google では、試験的に障害を発生させる取り組みを採用している Google におけるソフトウェアエンジニアリングの成果は、消費者向け製品 (Gmail 等) や基盤 (Bigtable 等) の他、舞台裏にも多く存在 など
本格的なソフトウェアプロジェクト
内部顧客と将来計画のロードマップによる製品ベースの思考
SRE 自身が直接の利害関係者なので、やりやすい
個々の SRE チームの生産性向上に重要である上に、SRE 組織全体としてもキャリア開発の提供やコーディングスキルを無駄にしたくないエンジニアに口を提供をできる
迅速に新しい製品や機能をリリースするための Site Reliability の役割 : サイトの安定性を損なうことなく急速な変化を可能にすること
Google における launch の定義 : 外部から見える変更をアプリケーションに導入する新しいコード